微观SOA：服务设计原则及其实践方式（上篇）

　　下篇：微观SOA：服务设计原则及其实践方式（下篇）

　　大量互联网公司都在拥抱SOA和服务化，但业界对SOA的很多讨论都比较偏向高大上。本文试图从稍微不同的角度，以相对接地气的方式来讨论SOA，集中讨论SOA在微观实践层面中的缘起、本质和具体操作方式，另外也用相当篇幅介绍了当今互联网行业中各种流行的远程调用技术等等，比较适合从事实际工作的架构师和程序员来阅读。

　　为了方便阅读，本话题将分为两篇展现。本文是上篇，着眼于微观SOA的定义，并简单分析其核心原则。

　　亚马逊CEO杰夫·贝佐斯：鲜为人知的SOA大师

　　由于SOA有相当的难度和门槛，不妨先从一个小故事说起，从中可以管窥一点SOA的大意和作用。

　　按照亚马逊前著名员工Steve Yegge著名的“酒后吐槽”，2002年左右，CEO贝佐斯就在亚马逊强制推行了以下六个原则（摘自酷壳）：

1. 所有团队的程序模块都要以通过Service Interface 方式将其数据与功能开放出来。
2. 团队间的程序模块的信息通信，都要通过这些接口。
3. 除此之外没有其它的通信方式。其他形式一概不允许：不能使用直接链结程序、不能直接读取其他团队的数据库、不能使用共享内存模式、不能使用别人模块的后门、等等，等等，唯一允许的通信方式只能是能过调用 Service Interface。
4. 任何技术都可以使用。比如：HTTP、Corba、Pubsub、自定义的网络协议、等等，都可以，贝佐斯不管这些。
5. 所有的Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。
6. 不这样的做的人会被炒鱿鱼。

　　据说，亚马逊网站展示一个产品明细的页面，可能要调用200-300个Service，以便生成高度个性化的内容。

　　Steve还提到：

Amazon已经把文化转变成了“一切以Service第一”为系统架构的公司，今天，这已经成为他们进行所有设计时的基础，包括那些绝不会被外界所知的仅在内部使用的功能。

那时，如果没有被解雇的的恐惧他们一定不会去做。我是说，他们今天仍然怕被解雇，因为这基本上是那儿每天的生活，为那恐怖的海盗头子贝佐斯工作。不过，他们这么做的确是因为他们已经相信Service这就是正确的方向。他们对于SOA的优点和缺点没有疑问，某些缺点还很大，也不疑问。但总的来说，这是正确的，因为，SOA驱动出来的设计会产生出平台（Platform）。

　　今天，我们都知道亚马逊从世界上最大图书卖场进化为了世界上最成功的云平台……

　　贝佐斯的六原则展示出高度的远见和超强的信念，即使放到十几年后的今天，依然觉得振聋发聩……想起一句老话：“不谋万世者，不足以谋一时；不谋全局者，不足以谋一隅。”

　　当然，像贝佐斯这种将神性与魔性集于一身的专横人物，既可能创造划时代的进步，也可能制造前所未有的灾难。

　　SOA漫谈：宏观与微观

　　SOA即面向服务架构，是一个特别大的话题。

　　为了方便讨论，我在此先草率的将SOA分为两个层面（大概模仿宏观和微观经济学，但这里的划分没有绝对界限）：

• 宏观SOA：面向高层次的部门级别、公司级别甚至行业级别；涉及商业、管理、技术等方面的综合的、全局的考虑；架构体系上包括服务治理（governance，如服务注册，服务监控），服务编排（orchestration，如BPM，ESB)，服务协同（choreography，更多面向跨企业集成）等等。我认为SOA本身最主要是面向宏观层面的架构，其带来益处也最能在宏观高层次上体现出来，同时大部分SOA的业界讨论也集中在这方面。
• 微观SOA：面向有限的、局部的团队和个人；涉及独立的、具体的服务在业务、架构、开发上的考虑。

　　很多业界专家都认为SOA概念过于抽象，不接地气，我认为主要是宏观SOA涉及面太广，经常需要做通盘考虑，而其中很多方面距离一般人又比较远。而在微观层面的SOA更容易达到涛哥过去提出的“三贴近”：贴近实际、贴近生活、贴近群众。

　　同时，宏观SOA要取得成功，通常的前提也是SOA在微观层面的落地与落实，正如宏观经济学一般要有坚实的微观基础（比如大名鼎鼎的凯恩斯主义曾广受诟病的一点就是缺乏微观基础）

　　因此，我们着眼于SOA落地的目的，着重来分析微观SOA，也算是对业界主流探讨的一个小小的补充。

　　SOA定义

　　按照英文维基百科定义：SOA是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用。

　　什么是“服务”？按照OASIS的定义：Service是一种按照既定“接口“来访问一个或多个软件功能的机制（另外这种访问要符合“服务描述”中策略和限制）

　　Service示例（代码通常以java示例）

public interface Echo {
    String echo(String text);
}

public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

　　可能每个开发人员每天都在写类似的面向对象的Service，难道这就是在实施SOA吗？

　　SOA设计原则

　　既然SOA是设计原则（模式），那么它包含哪些内容呢？事实上，这方面并没有最标准的答案，多数是遵从著名SOA专家Thomas Erl的归纳：

标准化的服务契约 Standardized service contract 服务的松耦合 Service loose coupling 服务的抽象 Service abstraction 服务的可重用性 Service reusability 服务的自治性 Service autonomy 服务的无状态性 Service statelessness 服务的可发现性 Service discoverability 服务的可组合性 Service composability ....

　　这些原则总的来说要达到的目的是：提高软件的重用性，减少开发和维护的成本，最终增加一个公司业务的敏捷度。

　　但是，业界著名专家如Don Box，David Orchard等人对SOA又有各自不同的总结和侧重。

　　SOA不但没有绝对统一的原则，而且很多原则本身的内容也具备相当模糊性和宽泛性：例如，所谓松耦合原则需要松散到什么程度才算是符合标准的呢？这就好比一个人要帅到什么程度才算是帅哥呢？一栋楼要高到多少米才算是高楼呢？可能不同人心中都有自己的一杆秤……部分由于这些理论上的不确定因素，不同的人理解或者实施的SOA事实上也可能有比较大的差别。

　　浅析松耦合原则

　　SOA原则比较多，真正的理解往往需要逐步的积累和体会，所以在此不详细展开。这里仅以服务的松耦合为例，从不同维度来简单剖析一下这个原则，以说明SOA原则内涵的丰富性：

• 实现的松耦合：这是最基本的松耦合，即服务消费端不需要依赖服务契约的某个特定实现，这样服务提供端的内部变更就不会影响到消费端，而且消费端未来还可以自由切换到该契约的其他提供方。

• 时间的松耦合：典型就是异步消息队列系统，由于有中介者（broker），所以生产者和消费者不必在同一时间都保持可用性以及相同的吞吐量，而且生产者也不需要马上等到回复。

• 位置的松耦合：典型就是服务注册中心和企业服务总线（ESB），消费端完全不需要直接知道提供端的具体位置，而都通过注册中心来查找或者服务总线来路由。

• 版本的松耦合：消费端不需要依赖服务契约的某个特定版本来工作，这就要求服务的契约在升级时要尽可能的提供向下兼容性。

　　SOA与传统软件设计

　　我们可以认为：SOA ≈ 模块化开发 + 分布式计算

　　将两者传统上的最佳实践结合在一起，基本上可以推导出SOA的多数设计原则。SOA从软件设计（暂不考虑业务架构之类）上来讲，自身的新东西其实不算很多。

　　SOA原则的应用

　　基于SOA的原则，也许我们很难说什么应用是绝对符合SOA的，但是却能剔除明显不符合SOA的应用。

　　用上述标准化契约，松耦合和可重用这几个原则来尝试分析一下上面Echo示例：

• Echo的服务契约是用Java接口定义，而不是一种与平台和语言无关的标准化协议，如WSDL，CORBA IDL。当然可以抬杠，Java也是行业标准，甚至全国牙防组一致认定的东西也是行业标准。

• Java接口大大加重了与Service客户端的耦合度，即要求客户端必须也是Java，或者JVM上的动态语言（如Groovy、Jython）等等……

• 同时，Echo是一个Java的本地接口，就要求调用者最好在同一个JVM进程之内……

• Echo的业务逻辑虽然简单独立，但以上技术方面的局限就导致它无法以后在其他场合被轻易重用，比如分布式环境，异构平台等等。

　　因此，我们可以认为Echo并不太符合SOA的基本设计原则。

　　透明化的转向SOA？

　　修改一下上面的Echo，添加Java EE的@WebServices注解（annotation）

@WebServices
public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

　　现在将Echo发布为Java WebServices，并由底层框架自动生成WSDL来作为标准化的服务契约，这样就能与远程的各种语言和平台互操作了，较好的解决了上面提到的松耦合和可重用的问题。按照一般的理解，Echo似乎就成为比较理想的SOA service了。

　　但是……即使这个极端简化的例子，也会引出不少很关键的问题，它们决定SOA设计开发的某些难度：

• 将一个普通的Java对象通过添加注解“透明的”变成WebServices就完成了从面向对象到面向服务的跨越？
• 通过Java接口生成WSDL服务契约是好的方式吗？
• WebServices是最合适远程访问技术吗？

　　面向对象和面向服务的对比

　　面向对象（OO）和面向服务（SO）在基础理念上有大量共通之处，比如都尽可能追求抽象、封装和低耦合。

　　但SO相对于OO，又有非常不同的典型应用场景，比如：

• 多数OO接口（interface）都只被有限的人使用（比如团队和部门内），而SO接口（或者叫契约）一般来说都不应该对使用者的范围作出太多的限定和假设（可以是不同部门，不同企业，不同国家）。还记得贝佐斯原则吗？“团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外”。

• 多数OO接口都只在进程内被访问，而SO接口通常都是被远程调用。

　　简单讲，就是SO接口使用范围比一般OO接口可能广泛得多。我们用网站打个比方：一个大型网站的web界面就是它整个系统入口点和边界，可能要面对全世界的访问者（所以经常会做国际化之类的工作），而系统内部传统的OO接口和程序则被隐藏在web界面之后，只被内部较小范围使用。而理想的SO接口和web界面一样，也是变成系统入口和边界，可能要对全世界开发者开放，因此SO在设计开发之中与OO相比其实会有很多不同。

　　小结

　　在前述比较抽象的SOA大原则的基础上，我们可尝试推导一些较细化和可操作的原则，在具体实践中体现SO的独特之处。请关注本系列文章的下篇！